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Les 


Introduction 


The Extensible Authentication Protocol (EAP) is an authentication 


framework that supports multiple authentication methods. The primary 
purpose is network access authentication, and a key-generating method 
is used when the lower layer wants to enforce access control. The 


EAP keying hierarchy defines two keys to be derived by all 
key-generating EAP methods: the Master Session Key (MSK) and the 
Extended MSK (EMSK). In the most common deployment scenario, an EAP 
peer and an EAP server authenticate each other through a third party 
known as the EAP authenticator. The EAP authenticator or an entity 
controlled by the EAP authenticator enforces access control. After 
successful authentication, the EAP server transports the MSK to the 
EAP authenticator; the EAP authenticator and the EAP peer establish 
Transient Session Keys (TSKs) using the MSK as the authentication 
key, key derivation key, or a key transport key, and use the TSK for 
per-packet access enforcement. 


When a peer moves from one authenticator to another, it is desirable 
to avoid a full EAP authentication to support fast handovers. The 
full EAP exchange with another run of the EAP method can take several 
round trips and significant time to complete, causing increased 
handover times. Some EAP methods specify the use of state from the 
initial authentication to optimize re-authentications by reducing the 
computational overhead (e.g., EAP Authentication and Key Agreement 
(EAP-AKA) [RFC4187]), but method-specific re-authentication takes at 
least 2 round trips with the original EAP server in most cases. It 
is also important to note that several methods do not offer support 
for re-authentication. 


Key sharing across authenticators is sometimes used as a practical 
solution to lower handover times. In that case, however, the 
compromise of one authenticator results in the compromise of key 
material established via other authenticators. Other solutions for 
fast re-authentication exist in the literature: for example, see 
Lopez, et al. [MSKHierarchy]; Clancy, et al. have described the EAP 
re-authentication problem statement in detail [RFC5169]. 


In conclusion, to achieve low latency handovers, there is a need for 
a method-independent re-authentication protocol that completes in 
less than 2 round trips, preferably with a local server. 


This document specifies EAP Re-authentication Extensions (ERXs) for 
efficient re-authentication using EAP. The protocol that uses these 
extensions is itself referred to as the EAP Re-authentication 
Protocol (ERP). It supports EAP method-independent re-authentication 
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for a peer that has valid, unexpired key material from a previously 
performed EAP authentication. The protocol and the key hierarchy 
required for EAP re-authentication are described in this document. 


Note that to support ERP, lower-layer specifications may need to be 
revised to allow carrying EAP messages that have a code value higher 
than 4 and to accommodate the peer-initiated nature of ERP. 
Specifically, the Internet Key Exchange (IKE) protocol [RFC5996] must 
be updated to carry ERP messages; work is in progress on this project 
[IKE-EXT-for-ERP]. 


1.1. Changes from RFC 5296 


This document obsoletes RFC 5296 but is fully backward compatible 
with that document. The changes introduced in this document focus on 
fixing issues that have surfaced since the publication of the 
original ERP specification [RFC5296]. An overview of some of the 
major changes is given below. 


o Co-location of the home EAP Re-authentication (ER) and EAP servers 
is no longer required (see the "ER Server" entry in Section 2). 


o The behavior of the authenticator and local ER server during the 
bootstrapping process has been clarified (Section 5.1); in 
particular, the authenticator and/or local ER server is now 
required to check for current possession of the root keys. 


o The authenticator is now recommended, rather than just allowed, to 
initiate the ERP conversation by means of the EAP-Initiate/ 
Re-auth-Start message (Section 5.3.1.1). 


In addition, many editorial changes have been made to improve the 
clarity of the document and to eliminate perceived ambiguities. A 
comprehensive list of changes is not given here for practical 
reasons. 


2. Terminology 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 


"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 
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This document uses the basic EAP terminology [RFC3748] and EMSK 
keying hierarchy terminology [RFC5295]. In addition, this document 
uses the following terms: 


ER Peer - An EAP peer that supports the EAP Re-authentication 
Protocol. All references to "peer" in this document imply an ER 
peer, unless specifically noted otherwise. 


ER Authenticator - An entity that supports the authenticator 
functionality for EAP re-authentication described in this 
document. All references to "authenticator" in this document 
imply an ER authenticator, unless specifically noted otherwise. 


ER Server - An entity that performs the server portion of ERP 
described here. This entity may or may not be an EAP server. All 
references to "server" in this document imply an ER server, unless 
specifically noted otherwise. An ER server is a logical entity; 
it may not necessarily be co-located with, or physically part of, 
a full EAP server. 


ERX - EAP re-authentication extensions. 

ERP - EAP Re-authentication Protocol. Uses the re-authentication 
extensions. 

rRK - re-authentication Root Key, derived from the EMSK or the 


Domain-Specific Root Key (DSRK). 
rIK - re-authentication Integrity Key, derived from the rRK. 


rMSK - re-authentication MSK. This is a per-authenticator key, 
derived from the rRK. 


keyName-NAI - ERP messages are integrity protected with the rIK or 
the DS-rIK. The use of rIK or DS-rIK for integrity protection of 
ERP messages is indicated by the EMSKname [RFC5295]; the protocol, 
which is ERP; and the realm, which indicates the domain name of 
the ER server. The EMSKname is copied into the username part of 
the Network Access Identifier (NAI). 


Domain - Refers to a "key management domain" as defined in Salowey, 
et al. [RFC5295]. For simplicity, it is referred to as "domain" 
in this document. The terms "home domain" and "local domain" are 


used to differentiate between the originating key management 
domain that performs the full EAP exchange with the peer and the 
local domain to which a peer may be attached at a given time. 
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3; 


ERP Description 


ERP allows a peer and server to mutually verify proof of possession 
of key material from an earlier EAP method run and to establish a 
security association between the peer and the authenticator. The 
authenticator acts as a pass-through entity for the re-authentication 
protocol in a manner similar to that of an EAP authenticator as 
described in Aboba, et al. [RFC3748]. ERP is a single round-trip 
exchange between the peer and the server; it is independent of the 
lower layer and the EAP method used during the full EAP exchange. 

The ER server may be in the home domain or in the same (visited) 
domain as the peer and the authenticator (i.e., the local domain). 


Figure 1 shows the protocol exchange. The first time the peer 
attaches to any network, it performs a full EAP exchange (shown in 
Figure 2) with the EAP server; as a result, an MSK is distributed to 
the EAP authenticator. The MSK is then used by the authenticator and 
the peer to establish TSKs as needed. At the time of the initial EAP 
exchange, the peer and the server also derive an EMSK, which is used 
to derive an rRK. More precisely, an rRK is derived from the EMSK or 
from a DSRK, which is itself derived from the EMSK. The rRK is only 
available to the peer and the ER server and is never handed out to 
any other entity. Further, an rIK is derived from the rRK; the peer 
and the ER server use the rIK to provide proof of possession while 
performing an ERP exchange. The rIK is also never handed out to any 
entity and is only available to the peer and server. 


Peer ER Authenticator ER Server 


<-- EAP-Initiate/ ----- 
Re-auth-Start 
[<-- EAP-Request/ ------ 


Identity] 
=--- EAP-Initiate/ ----> ----AAA(EAP-Initiate/ ---------- > 
Re-auth/ Re-auth/ 
[Bootstrap] [Bootstrap] ) 
<--- EAP-Finish/ ------ > <---AAA (rMSK, EAP-Finish/--------- 
Re-auth/ Re-auth/ 
[Bootstrap] [Bootstrap] ) 
Note: [] brackets indicate optionality. 


Figure 1: ERP Exchange 
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EAP Peer EAP Authenticator EAP Server 
<--- EAP-Request/ ------ 
Identity 
----- EAP Response/ ---> 
Identity --—-AAA (EAP Response/Identity)--> 
<--- EAP Method ------- > RO AAA (EAP Method -------- > 
exchange exchange) 
<-—--—-AAA (MSK, EAP-Success)------ 


$==-EAP=5UCtess>===>==>= 
Figure 2: EAP Authentication 


Two EAP codes -- EAP-Initiate and EAP-Finish —- are specified in this 
document for the purpose of EAP re-authentication. When the peer 
identifies a target authenticator that supports EAP 
re-authentication, it performs an ERP exchange, as shown in Figure 1; 
the exchange itself may happen when the peer attaches to a new 
authenticator supporting EAP re-authentication, or prior to 
attachment. The peer initiates ERP by itself; it may also do so in 
response to an EAP-Initiate/Re-auth-Start message from the new 
authenticator. The EAP-Initiate/Re-auth-Start message allows the 


authenticator to trigger the ERP exchange. The EAP-Finish message 
also can be used by the authenticator to announce the local domain 
name. 


It is plausible that the authenticator does not know whether the peer 
supports ERP and whether the peer has performed a full EAP 
authentication through another authenticator. The authenticator MAY 
initiate the ERP exchange by sending the EAP-Initiate/Re-auth-Start 
message and if there is no response MAY send the EAP-Request/Identity 
message. Note that this avoids having two EAP messages in flight at 
the same time [RFC3748]. The authenticator may send the 
EAP-Initiate/Re-auth-Start message and wait for a short, locally 
configured amount of time. This message indicates to the peer that 
the authenticator supports ERP. In response to this trigger from the 
authenticator, the peer can initiate the ERP exchange by sending an 
EAP-Initiate/Re-auth message. If there is no response from the peer 
after the necessary number of retransmissions (see Section 6), the 
authenticator MUST initiate EAP by sending an EAP-Request message, 
typically the EAP-Request/Identity message. Note that the 
authenticator may receive an EAP-Initiate/Re-auth message after it 
has sent an EAP-Request/Identity message. If the authenticator 
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supports ERP, it MUST proceed with the ERP exchange. When the 
EAP-Request/Identity times out, the authenticator MUST NOT close the 
connection if an ERP exchange is in progress or has already succeeded 
in establishing a re-authentication MSK. 


If the authenticator does not support ERP, it will silently discard 
EAP-Initiate/Re-auth messages (Section 5.3.2), since the EAP code of 
those packets is greater than 4 ([RFC3748], Section 4). An ERP- 
capable peer will exhaust the EAP-Initiate/Re-auth message 
retransmissions and fall back to EAP authentication by responding to 
EAP-Request/Identity messages from the authenticator. If the peer 
does not support ERP or if it does not have unexpired key material 
from a previous EAP authentication, it drops EAP-Initiate/ 
Re-auth-Start messages. If there is no response to the EAP-Initiate/ 
Re-auth-Start message, the authenticator SHALL send an EAP-Request 
message (typically EAP-Request/Identity) to start EAP authentication. 
From this point onward, RFC 3748 rules apply. Note that this may 
introduce some delay in starting EAP. In some lower layers, the 
delay can be minimized or even avoided by the peer initiating EAP by 
sending messages such as EAPoL-Start [IEEE_802.1X]. 


The peer sends an EAP-Initiate/Re-auth message that contains the 
keyName-NAI to identify the ER server’s domain and the rIK used to 
protect the message, and a sequence number for replay protection. 

The EAP-Initiate/Re-auth message is integrity protected with the rIK. 
The authenticator uses the realm in the keyName-NAI field to send the 
message to the appropriate ER server. The server uses the keyName to 
look up the rIK. The server, after verifying proof of possession of 
the rIK and freshness of the message, derives an rMSK from the rRK 
using the sequence number as an input to the key derivation. The 
server then updates the expected sequence number to the received 
sequence number plus one. 


In response to the EAP-Initiate/Re-auth message, the server sends an 
EAP-Finish/Re-auth message; this message is integrity protected with 
the rIK. The server transports the rMSK along with this message to 
the authenticator. The rMSK is transported in a manner similar to 
that of the MSK along with the EAP-Success message in a full EAP 
exchange. Hoeper, et al. [RFC5749] discuss an additional key 
distribution protocol that can be used to transport the rRK from an 
EAP server to one of many different ER servers that share a trust 
relationship with the EAP server. 


The peer MAY request the rMSK lifetime from the server. If so, the 
ER server sends the rMSK lifetime in the EAP-Finish/Re-auth message. 
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In an ERP bootstrap exchange, the peer MAY ask the server for the rRK 
lifetime. If so, the ER server sends the rRK lifetime in the 
EAP-Finish/Re-auth message. 


The peer verifies the sequence number and the integrity of the 
message. It then uses the sequence number in the EAP-Finish/Re-auth 
message to compute the rMSK. The lower-layer security association 
protocol is ready to be triggered after this point. 


The ER server is located either in the home domain or in the visited 
domain. When the ER server is in the home domain and there is no 
local ER server in the visited domain, the peer and the server use 
the rIK and rRK derived from the EMSK; and when the ER server is in 
the local domain, they use the DS-rIK and DS-rRK corresponding to the 
local domain. The domain of the ER server is identified by the realm 
portion of the keyName-NAI in ERP messages. 


3.1. ERP with the Home ER Server 


If the peer is in the home domain or there is no local server in the 
same domain as the peer, it SHOULD initiate an ERP bootstrap exchange 
with the home ER server to obtain the domain name. 


The defined ER extensions allow executing ERP with an ER server in 
the home domain. The home ER server may be co-located with a home 
Authentication, Authorization, and Accounting (AAA) server. ERP with 
the home ER server is similar to the ERP exchange described in 

Figure 1. 


Peer ER Authenticator Home ER Server 


<-- EAP-Initiate/ ----- 
Re-auth-Start 
[<-- EAP-Request/ ------ 


Identity] 
---- EAP-Initiate/ ----> ----AAA(EAP-Initiate/ ---------- > 
Re-auth/ Re-auth/ 
Bootstrap Bootstrap) 
<--- EAP-Finish/ ------ > <---AAA (rMSK, EAP-Finish/--------- 
Re-auth/ Re-auth/ 
Bootstrap Bootstrap) 


Figure 3: ER Explicit Bootstrapping Exchange/ERP 
with the Home ER Server 
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3.2. ERP with a Local ER Server 


The defined ER extensions allow the execution of ERP with an ER 
server in the local domain (access network) if the peer moves out of 
the home domain and a local ER server is present in the visited 
domain. The local ER server may be co-located with a local AAA 
server. The peer may learn about the presence of a local ER server 
in the network and the local domain name (or ER server name) either 
via a lower-layer advertisement or by means of an ERP exchange. The 
peer uses the domain name and the EMSK to compute the DSRK and, from 
that key, the DS-rRK; the peer also uses the domain name in the realm 
portion of the keyName-NAI for using ERP in the local domain. 

Figure 4 shows the ER implicit bootstrapping exchange through a local 
ER server; Figure 5 shows ERP with a local ER server. 


EAP Authenticator Local AAA Agent 
Peer /ER Authenticator /Local ER Server Home EAP Server 


<-- EAP-Request/ -- 


Identity 
-- EAP Response/--> 

Identity --AAA (EAP Response/--> 

Identity, -—AAA(EAP Response/ --> 
[domain name]) Identity, 
[DSRK Request, 
domain name]) 

e ei EAP Method exchange------------------ > 


<---AAA(MSK, DSRK, ---- 
EMSKname, 
EAP-Success) 


<--- AAA(MSK, ----- 
EAP-Success) 


<---EAP-Success----- 


Figure 4: Implicit Bootstrapping ERP Exchange, Initial EAP Exchange 
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Peer ER Authenticator Local ER Server 


<-- EAP-Initiate/ -------- 
Re-auth-Start 
[<-- EAP-Request/ --------- 


Identity] 
---- EAP-Initiate/ ------- > ----AAA(EAP-Initiate/ -------- > 
Re-auth Re-auth) 
<--- EAP-Finish/ ---------- <---AAA (rMSK, EAP-Finish/------- 
Re-auth Re-auth) 


Figure 5: Local ERP Exchange 


As shown in Figure 4, the local ER server may be present in the path 
of the full EAP exchange (e.g., this may be one of the AAA entities, 
such as AAA proxies, in the path between the EAP authenticator and 
the home EAP server of the peer). In that case, the local ER server 
requests the DSRK by sending the domain name to the home EAP server 
by means of a AAA message. In response, the home EAP server computes 
the DSRK by following the procedure specified in RFC 5295 and sends 
the DSRK and the key name, EMSKname, to the ER server in the claimed 
domain (i.e., the local ER server). The local domain is responsible 
for announcing that same domain name to the peer via a lower layer 
(for example, through DHCP-based local domain name discovery 
[RFC6440] or through the EAP-Initiate/Re-auth-Start message with the 
local ER server). 


After receiving the DSRK and the EMSKname, the local ER server 
computes the DS-rRK and the DS-rIK from the DSRK as defined in 
Sections 4.1 and 4.3 below. After receiving the domain name, the 
peer also derives the DSRK, the DS-rRK, and the DS-rIK. These keys 
are referred to by a keyName-NAI formed as follows: the username part 
of the NAI is the EMSKname, and the realm portion of the NAI is the 
domain name. Both parties also maintain a sequence number 
(initialized to zero) corresponding to the specific keyName-NAI. 


If the peer subsequently attaches to an authenticator within the 
local domain, it may perform an ERP exchange with the local ER server 
to obtain an rMSK for the new authenticator. ERP with the local ER 
server is similar to the ERP exchange illustrated in Figure 1. 
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4. ER Key Hierarchy 


Each time the peer re-authenticates to the network, the peer and the 
authenticator establish an rMSK. The rMSK serves the same purposes 
that an MSK, which is the result of full EAP authentication, serves. 
To prove possession of the rRK, we specify the derivation of another 
key, the rIK. These keys are derived from the rRK. Together they 
constitute the ER key hierarchy. 


The rRK is derived from either the EMSK or a DSRK as specified in 
Section 4.1. For the purpose of rRK derivation, this document 
specifies derivation of a Usage-Specific Root Key (USRK) or a Domain- 
Specific USRK (DSUSRK) [RFC5295] for re-authentication. The USRK 
designated for re-authentication is the rRK. A DSUSRK designated for 
re-authentication is the DS-rRK available to a local ER server ina 
particular domain. For simplicity, the keys are referred to without 
the DS label in the rest of the document. However, the scope of the 
various keys is limited to just the respective domains for which they 
are derived, in the case of the domain-specific keys. Based on the 
ER server with which the peer performs the ERP exchange, it knows the 
corresponding keys that must be used. 


The rRK is used to derive an rIK and rMSKs for one or more 
authenticators. The figure below shows the key hierarchy with the 
rRK, rIK, and rMSKs. 


rRK 
| 
4+-------- 4+-------- + 
| | 
rik rMSK1 ...rMSKn 


Figure 6: Re-authentication Key Hierarchy 


The derivations in this document are from RFC 5295. Key derivations 
and field encodings, where unspecified, default to that document. 


4.1. rRK Derivation 


The rRK may be derived from the EMSK or DSRK. This section provides 
the relevant key derivations for that purpose. 


The rRK is derived as specified in RFC 5295. 
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rRK = KDF (K, S), where 


K 


EMSK or K = DSRK and 
S = rRK Label | "NO" | length 

The rRK Label is an IANA-assigned 8-bit ASCII string: 
EAP Re-authentication Root Key@ietf.org 


assigned from the "USRK Key Labels" name space in accordance with the 
policy stated in RFC 5295. 


The Key Derivation Function (KDF) and algorithm agility for the KDF 
are as defined in RFC 5295. 


An rRK derived from the DSRK is referred to as a DS-rRK in the rest 
of the document. All of the key derivation and properties specified 
in this section remain the same. 


4.2. rRK Properties 


The rRK has the following properties. These properties apply to the 
rRK regardless of the parent key used to derive it. 


o The length of the rRK MUST be equal to the length of the parent 
key used to derive it. 


o The rRK is to be used only as a root key for re-authentication and 
never used to directly protect any data. 


o The rRK is only used for the derivation of the rIK and rMSK as 
specified in this document. 


o The rRK MUST remain on the peer and the server that derived it and 
MUST NOT be transported to any other entity. 


o The lifetime of the rRK is never greater than that of its parent 
key. The rRK is expired when the parent key expires and MUST be 
removed from use at that time. 


4.3. rIK Derivation 
The rIK is used for integrity protecting the ERP exchange. This 


serves as the proof of possession of valid key material from a 
previous full EAP exchange by the peer to the server. 
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The rIK is derived as follows: 
rIK = KDF (K, S), where 


K = rRK and 


S rIK Label | "NO" | cryptosuite | length 


The rIK Label is the 8-bit ASCII string: 
Re-authentication Integrity Key@ietf.org 


The length field refers to the length of the rIK in octets and is 
encoded as specified in RFC 5295. 


The cryptosuite and length of the rIK are part of the input to the 
KDF to ensure cryptographic separation of keys if different rIKs of 
different lengths (for example, for use with different Message 
Authentication Code (MAC) algorithms) are derived from the same rRK. 
The cryptosuite is encoded as an 8-bit number; see Section 5.3.2 for 
the cryptosuite specification. 


The rIK is referred to by the EMSKname-NAI within the context of ERP 
messages. The username part of the EMSKname-NAI is the EMSKname; the 
realm is the domain name of the ER server. In the case of ERP with 


the home ER server, the peer uses the realm from its original NAI; in 
the case of a local ER server, the peer uses the domain name received 
at the lower layer or through an ERP bootstrapping exchange. 


An rIK derived from a DS-rRK is referred to as a DS-rIK in the rest 
of the document. All of the key derivation and properties specified 
in this section remain the same. 

4.4. rIK Properties 
The rIK has the following properties: 


o The length of the rIK MUST be equal to the length of the rRK. 


o The rIK is only used for authentication of the ERP exchange as 
specified in this document. 


o The rIK MUST NOT be used to derive any other keys. 


o The rIK must remain on the peer and the server and MUST NOT be 
transported to any other entity. 
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o The rIK is cryptographically separate from any other keys derived 
from the rRkK. 


o The lifetime of the rIK is never greater than that of its parent 
key. The rIK MUST be expired when the EMSK expires and MUST be 
removed from use at that time. 


4.5. rIK Usage 


The rIK is the key the possession of which is demonstrated by the 
peer and the ERP server to the other party. The peer demonstrates 
possession of the rIK by computing the integrity checksum over the 
EAP-Initiate/Re-auth message. When the peer uses the rIK for the 
first time, it can choose the integrity algorithm to use with the 
rIK. The peer and the server MUST use the same integrity algorithm 
with a given rIK for all ERP messages protected with that key. The 
peer and the server store the algorithm information after the first 
use, and they employ the same algorithm for all subsequent uses of 
that rIK. 


If the server's policy does not allow the use of the cryptosuite 
selected by the peer, the server SHALL reject the EAP-Initiate/ 
Re-auth message and SHOULD send a list of acceptable cryptosuites in 
the EAP-Finish/Re-auth message. 


The rIK length may be different from the key length required by an 
integrity algorithm. In the case of hash-based MAC algorithms, the 
key is first hashed to the required key length using the HMAC 
algorithm [RFC2104]. In the case of cipher-based MAC algorithms, if 
the required key length is less than 32 octets, the rIK is hashed 
using HMAC-SHA256 and the first k octets of the output are used, 
where k is the key length required by the algorithm. If the required 
key length is more than 32 octets, the first k octets of the rIK are 
used by the cipher-based MAC algorithm. 


4.6. rMSK Derivation 


The rMSK is derived at the peer and server and delivered to the 
authenticator. The rMSK is derived following an ERP exchange. 


The rMSK is derived as follows: 


rMSK = KDF (K, S), where 
K = rRK and 
S = rMSK Label | "NO" | SEQ | length 
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The rMSK Label is the 8-bit ASCII string: 
Re-authentication Master Session Key@ietf.org 


The length field refers to the length of the rMSK in octets and is 
encoded as specified in RFC 5295. 


SEQ is the sequence number sent by the peer in the EAP-Initiate/ 
Re-auth message. This field is encoded as a 16-bit number in network 
byte order (see Section 5.3.2). 


An rMSK derived from a DS-rRK is referred to as a DS-rIK in the rest 
of the document. The key derivation and properties specified in this 
section remain the same. 

4.7. YMSK Properties 
The rMSK has the following properties: 
o The length of the rMSK MUST be equal to the length of the rRK. 
o The rMSK is delivered to the authenticator and is used for the 


same purposes that an MSK serves when the MSK is used at an 
authenticator. 


o The rMSK is cryptographically separate from any other keys derived 
from the rRK. 


o The lifetime of the rMSK is less than or equal to that of the rRK. 
It MUST NOT be greater than the lifetime of the rRK. 


o If a new rRK is derived, subsequent rMSKs MUST be derived from the 
new rRK. Previously delivered rMSKs MAY still be used until the 
expiry of the lifetime. 


o A given rMSK MUST NOT be shared by multiple authenticators. 
5. Protocol Details 
5.1. ERP Bootstrapping 


We identify two types of bootstrapping for ERP: explicit and 
implicit. In implicit bootstrapping, the ER-capable authenticator or 
local ER server MUST verify whether it has a valid rMSK or rRK 
corresponding to the peer. If the ER-capable authenticator or the 
local ER server has the key material corresponding to the peer, it 
MUST be able to respond directly in the same way as the home AAA 
server does without forwarding the DSRK Request to the home domain; 
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if not, the ER-capable authenticator or local ER server SHOULD 
include its domain name in the AAA message encapsulating the first 
EAP Response message sent by the peer and request the DSRK from the 
home EAP server during the initial EAP exchange. If such an EAP 
exchange is successful, the home EAP server sends the DSRK for the 
specified local AAA client or agent (derived using the EMSK and the 
domain name as specified in RFC 5295), EMSKname, and DSRK lifetime 
along with the EAP-Success message. The local AAA client or agent 
MUST extract the DSRK, EMSKname, and DSRK lifetime (if present) 
before forwarding the EAP-Success message to the peer. Note that the 
MSK (also present with the EAP-Success message) is extracted by the 
EAP authenticator as usual. The peer learns the domain name through 
the EAP-Initiate/Re-auth-Start message or by means of a lower-layer 
announcement (for example, DHCP [RFC6440]). When the domain name is 
available to the peer during or after the full EAP authentication, it 
attempts to use ERP when it associates with a new authenticator. 


If the peer knows there is no local ER server present in the visited 
domain, it SHOULD initiate ERP explicit bootstrapping (ERP exchange 
with the bootstrap flag turned on) with the home ER server to obtain 
the rRK. The peer MAY also initiate bootstrapping to fetch 
information such as the rRK lifetime from the AAA server. 


The following steps describe the ERP explicit bootstrapping process: 


o The peer sends the EAP-Initiate/Re-auth message with the 
bootstrapping flag set (1). The bootstrap message is always sent 
to the home ER server, and the keyName-NAI attribute in the 
bootstrap message is constructed as follows: the username portion 
of the NAI contains the EMSKname, and the realm portion contains 
the home domain name. 


o In addition, the message MUST contain a sequence number for replay 
protection, a cryptosuite, and an integrity checksum. The 
cryptosuite indicates the authentication algorithm. The integrity 
checksum indicates that the message originated at the claimed 
entity, the peer indicated by the Peer-ID, or the rIKname. 


o The peer MAY additionally set the lifetime flag to request the key 
lifetimes. 


o Upon receipt of the EAP-Initiate/Re-auth message from a peer, the 
ERP-capable authenticator verifies whether it has the local domain 
name and valid key material corresponding to the peer. If it 
knows the local domain name and has valid key material 
corresponding to the peer, it MUST be able to respond directly in 
the same way as the home ER does, with the local domain name 
included. If not, it copies the contents of the keyName-NAI into 
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the appropriate AAA attribute and may include its domain name in 
the AAA message encapsulating the EAP-Initiate/Re-auth message 
sent by the peer. 


o Upon receipt of an EAP-Initiate/Re-auth message, the home ER 
server verifies whether the message is fresh or is a replay by 
evaluating whether the received sequence number is equal to or 
greater than the expected sequence number for that rIK. The home 
ER server then verifies that the cryptosuite used by the peer is 
acceptable. Next, it verifies the integrity of the message by 
looking up the rIK and checking the integrity checksum contained 
in the Authentication Tag field. If any of the checks fail, the 
home ER server sends an EAP-Finish/Re-auth message with the Result 
flag set to '1'. Please refer to Section 5.2.2 for details on 
failure handling. This error MUST NOT have any correlation to any 
EAP-Success message that may have been received by the EAP 
authenticator and the peer earlier. If the EAP-Initiate/Re-auth 
message is well formed and valid, the server prepares the 
EAP-Finish/Re-auth message. The bootstrap flag MUST be set to 
indicate that this is a bootstrapping exchange. The message 
contains the following fields: 


* A sequence number for replay protection. 


* The same keyName-NAI as in the EAP-Initiate/Re-auth message. 


* If the lifetime flag was set in the EAP-Initiate/Re-auth 
message, the ER server SHOULD include the rRK lifetime and the 
rMSK lifetime in the EAP-Finish/Re-auth message. The server 
may have a local policy for the network to maintain and enforce 
lifetime unilaterally. In such cases, the server need not 
respond to the peer's request for the lifetime. 


* If the bootstrap flag is set, the ER server MUST include the 
domain name to which the DSRK is being sent along with the 
EAP-Finish/Re-auth message. 


* If the ER server verifies the authorization of a local ER 
server, it MAY include the Authorization Indication TLV to 
indicate to the peer that the server that received the DSRK and 
that is advertising the domain included in the Domain name TLV 
is authorized. 


* An authentication tag MUST be included to prove that the 


EAP-Finish/Re-auth message originates at a server that 
possesses the rIK corresponding to the EMSKname-NAI. 
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o If the home ER server is involved in the ERP exchange and the ERP 
exchange is successful, the home ER server SHOULD request the DSRK 
from the home EAP server; the home EAP server MUST provide the 
DSRK for the home ER server (derived using the EMSK and the domain 
name as specified in RFC 5295), EMSKname, and DSRK lifetime for 
inclusion in the AAA message. The home ER server SHOULD obtain 
them before sending the EAP-Finish/Re-auth message. 


o In addition, the rMSK is sent along with the EAP-Finish/Re-auth 
message in a AAA attribute (for an example, see Bournelle, 
et al. [DIAMETER-ERP]). 


o The authenticator receives the rMSK. 


o When the peer receives an EAP-Finish/Re-auth message with the 
bootstrap flag set, if a local domain name is present, it MUST use 
that name to derive the appropriate DSRK, DS-rRK, DS-rIK, and 
keyName-NAI, and initialize the replay counter for the DS-rIK. If 
not, the peer SHOULD derive the domain-specific keys using the 
domain name it learned via the lower layer or from the 
EAP-Initiate/Re-auth-Start message. If the peer does not know the 
domain name, it must assume that there is no local ER server 
available. 


o The peer MAY also verify the Authorization Indication TLV. 


o The procedures for encapsulating ERP and obtaining relevant keys 
using Diameter are specified in Bournelle, et al. [DIAMETER-ERP]. 


Since the ER bootstrapping exchange is typically done immediately 
following the full EAP exchange, it is feasible that the process is 
completed through the same entity that served as the EAP 
authenticator for the full EAP exchange. In this case, the lower 
layer may already have established TSKs based on the MSK received 
earlier. The lower layer may then choose to ignore the rMSK that was 
received with the ER bootstrapping exchange. Alternatively, the 
lower layer may choose to establish a new TSK using the rMSK. In 
either case, the authenticator and the peer know which key is used 
based on whether or not a TSK establishment exchange is initiated. 
The bootstrapping exchange may also be carried out via a new 
authenticator, in which case, the rMSK received SHOULD trigger a 
lower-layer TSK establishment exchange. 


5.2. Steps in ERP 
When a peer that has an active rRK and rIK associates with a new 


authenticator that supports ERP, it may perform an ERP exchange with 
that authenticator. ERP is typically a peer-initiated exchange, 
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consisting of an EAP-Initiate/Re-auth and an EAP-Finish/Re-auth 
message. The ERP exchange may be performed with a local ER server 
(when one is present) or with the original EAP server. 


It is plausible for the network to trigger the EAP re-authentication 
process, however. An ERP-capable authenticator SHOULD send an 
EAP-Initiate/Re-auth-Start message to indicate support for ERP. The 
peer may or may not wait for these messages to arrive to initiate the 
EAP-Initiate/Re-auth message. 


The EAP-Initiate/Re-auth-Start message SHOULD be sent by an ERP- 
capable authenticator. The authenticator may retransmit it a few 
times until it receives an EAP-Initiate/Re-auth message in response 
from the peer. The EAP-Initiate/Re-auth message from the peer may 
have originated before the peer receives either an EAP-Request/ 
Identity or an EAP-Initiate/Re-auth-Start message from the 
authenticator. Hence, the Identifier value in the EAP-Initiate/ 
Re-auth message is independent of the Identifier value in the 
EAP-Initiate/Re-auth-Start or EAP-Request/Identity messages. 


Operational Considerations at the Peer: 

ERP requires that the peer maintain retransmission timers for 
reliable transport of EAP re-authentication messages. The 
reliability considerations of Section 4.3 of RFC 3748 apply with the 
peer as the retransmitting entity. 


ERP has the following steps: 


o The ERP-capable authenticator sends the EAP-Initiate/Re-auth-Start 
message to trigger the ERP exchange. 


o The peer sends an EAP-Initiate/Re-auth message. At a minimum, the 
message SHALL include the following fields: 


* a 16-bit sequence number for replay protection. 


* keyName-NAI as a TLV attribute to identify the rIK used to 
integrity protect the message. 


* cryptosuite to indicate the authentication algorithm used to 
compute the integrity checksum. 


* authentication tag computed over the message. 
o When the peer is performing ERP with a local ER server, it MUST 


use the corresponding DS-rIK it shares with the local ER server. 
The peer SHOULD set the lifetime flag to request the key lifetimes 
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from the server. The peer can use the rRK lifetime to know when 
to trigger an EAP method exchange and the rMSK lifetime to know 
when to trigger another ERP exchange. 


o The authenticator copies the contents of the value field of the 
keyName-NAI TLV into an appropriate attribute (e.g., User-Name 
[RFC2865]) in the AAA message to the ER server. 


o The ER server uses the keyName-NAI to look up the rIK. It MUST 
first verify whether the sequence number is equal to or greater 
than the expected sequence number. If the ER server supports a 
sequence number window size greater than 1, it MUST verify whether 
the sequence number falls within the window and has not been 
received before. The ER server MUST then verify that the 
cryptosuite used by the peer is acceptable. The ER server then 
proceeds to verify the integrity of the message using the rIK, 
thereby verifying proof of possession of that key by the peer. If 
any of these verifications fail, the ER server MUST send an 
EAP-Finish/Re-auth message with the Result flag set to ’1’ 
(Failure). Please refer to Section 5.2.2 for details on failure 
handling. Otherwise, it MUST compute an rMSK from the rRK using 
the sequence number as the additional input to the key derivation. 


o In response to a well-formed EAP-Initiate/Re-auth message, the ER 
server MUST send an EAP-Finish/Re-auth message with the following 
contents: 


* a 16-bit sequence number for replay protection, which MUST be 
the same as the received sequence number. The local copy of 
the sequence number MUST be incremented by 1. If the ER server 
supports multiple simultaneous ERP exchanges, it MUST instead 
update the sequence number window. 


* keyName-NAI as a TLV attribute to identify the rIK used to 
integrity protect the message. 


* cryptosuite to indicate the authentication algorithm used to 
compute the integrity checksum. 


* authentication tag computed over the message. 
* If the lifetime flag was set in the EAP-Initiate/Re-auth 


message, the ER server SHOULD include the rRK lifetime and the 
rMSK lifetime. 
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o The ER server causes the rMSK along with this message to be 
transported to the authenticator. The rMSK is transported in a 
manner similar to the MSK and the EAP-Success message in a regular 
EAP exchange. 


o The peer looks up the sequence number to verify whether it is 
expecting an EAP-Finish/Re-auth message with that sequence number 
protected by the keyName-NAI. It then verifies the integrity of 
the message. If the verifications fail, the peer logs an error 
and stops the process; otherwise, it proceeds to the next step. 


o The peer uses the sequence number to compute the rMSK. 


o The lower-layer security association protocol can be triggered at 
this point. 


5.2.1. Multiple Simultaneous Runs of ERP 


When a peer is within the range of multiple authenticators, it may 
choose to run ERP via all of them simultaneously to the same ER 
server. In that case, it is plausible that the ERP messages may 
arrive out of order, resulting in the ER server rejecting legitimate 
EAP-Initiate/Re-auth messages. 


To facilitate such operation, an ER server MAY allow multiple 
simultaneous ERP exchanges by accepting all EAP-Initiate/Re-auth 
messages with sequence number values within a window of allowed 
values. Recall that the sequence number allows replay protection. 
Replay window maintenance mechanisms are a local matter. 


5.2.2. ERP Failure Handling 


If the processing of the EAP-Initiate/Re-auth message results in a 
failure, the ER server MUST send an EAP-Finish/Re-auth message with 
the Result flag set to '1'. If the server has a valid rIK for the 
peer, it MUST integrity protect the EAP-Finish/Re-auth failure 
message. If the failure is due to an unacceptable cryptosuite, the 
server SHOULD send a list of acceptable cryptosuites (in a TLV of 
Type 5) along with the EAP-Finish/Re-auth message. In this case, the 
server MUST indicate the cryptosuite used to protect the EAP-Finish/ 
Re-auth message in the Cryptosuite field of that message. The rIK 
used with the EAP-Finish/Re-auth message in this case MUST be 
computed as specified in Section 4.3 using the new cryptosuite. If 
the server does not have a valid rIK for the peer, the EAP-Finish/ 
Re-auth message indicating a failure will be unauthenticated; the 
server MAY include a list of acceptable cryptosuites in the message. 
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The peer, upon receiving an EAP-Finish/Re-auth message with the 
Result flag set to '1', MUST verify the sequence number and, if 
possible, the authentication tag to determine the validity of the 
message. If the peer supports the cryptosuite, it MUST verify the 
integrity of the received EAP-Finish/Re-auth message. If the 
EAP-Finish message contains a TLV of Type 5, the peer SHOULD retry 
the ERP exchange with a cryptosuite picked from the list included by 
the server. The peer MUST use the appropriate rIK for the subsequent 
ERP exchange by computing it with the corresponding cryptosuite, as 
specified in Section 4.3. If the Pseudo-Random Function (PRF) in the 
chosen cryptosuite is different from the PRF originally used by the 
peer, it MUST derive a new DSRK (if required), rRK, and rIK before 
proceeding with the subsequent ERP exchange. 


If the peer cannot verify the integrity of the received message, it 
MAY choose to retry the ERP exchange with one of the cryptosuites in 
the list of acceptable cryptosuites (in a TLV of Type 5), after a 
failure has been clearly determined following the procedure in the 
next paragraph. 


If the replay or integrity checks fail, the failure message may have 
been sent by an attacker. It may also mean that the server and peer 
do not support the same cryptosuites; however, the peer cannot 
determine if that is the case. Hence, the peer SHOULD continue the 
ERP exchange per the retransmission timers before declaring a 
failure. 


When the peer runs explicit bootstrapping (ERP with the bootstrapping 
flag on), there may not be a local ER server available to send a DSRK 
Request and the domain name. In that case, the server cannot send 
the DSRK and MUST NOT include the Domain name TLV. When the peer 
receives a response in the bootstrapping exchange without a Domain 
name TLV, it assumes that there is no local ER server. The home ER 
server sends an rMSK to the ER authenticator, however, and the peer 
SHALL run the TSK establishment protocol as usual. 
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EAP Codes 


Two EAP codes are defined for the purpose of ERP: EAP-Initiate and 
EAP-Finish. The packet format for these messages follows the EAP 
packet format defined in Aboba, et al. [RFC3748]. 


0 


1 2 3 


OL123 4567.8 90123456789 0123-495 67 8.9 0 1 
E 


Code | Identifier | Length 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Type | Type-Data 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
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Figure 7: EAP Packet 


Code 


Two code values are defined for the purpose of ERP: 
5 Initiate 


6 Finish 


Identifier 


The Identifier field is one octet. The Identifier field MUST 
be the same if an EAP-Initiate packet is retransmitted due to a 
timeout while waiting for an EAP-Finish message. Any new 
(non-retransmission) EAP-Initiate message MUST use a new 
Identifier field. 


The Identifier field of the EAP-Finish message MUST match that 
of the currently outstanding EAP-Initiate message. A peer or 
authenticator receiving an EAP-Finish message whose Identifier 
value does not match that of the currently outstanding 
EAP-Initiate message MUST silently discard the packet. 


In order to avoid confusion between new EAP-Initiate messages 
and retransmissions, the peer must choose an Identifier value 
that is different from the previous EAP-Initiate message, 
especially if that exchange has not finished. It is 
RECOMMENDED that the authenticator clear EAP Re-auth state 
after 300 seconds. 
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Type 
This field indicates that this is an ERP exchange. Two type 
values are defined in this document for this purpose -- 
Re-auth-Start (Type 1) and Re-auth (Type 2). 

Type-Data 


The Type-Data field varies according to the value of the Type 
field in the re-authentication packet. 


5.3.1. EAP-Initiate/Re-auth-Start Packet 


The EAP-Initiate/Re-auth-Start packet contains the fields shown in 
Figure 8. 


0 1 2 3 
001.223 Ao 1 38. 90 Ay 24304 9 6 08 9000 1: 23 46 189 0. 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ 


| Code | Identifier | Length 
E e e ho o ooo ++ 
| Type | Reserved | 1 or more TVs or TLVs = 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Figure 8: EAP-Initiate/Re-auth-Start Packet 
Type = 1. 


Reserved: MUST be zero. Set to zero on transmission and ignored 
on reception. 


One or more Type/Values (TVs) or TLVs are used to convey 
information to the peer; for instance, the authenticator may send 
the domain name to the peer. 


TVs or TLVs: In the TV payloads, there is a l-octet type payload 
and a value with type-specific length. In the TLV payloads, 
there is a l-octet type payload and a 1-octet length payload. 
The length field indicates the length of the value expressed in 
number of octets. 


Domain name: This is a TLV payload. The Type is 4. The 
domain name is to be used as the realm in an NAI [RFC4282]. 
The Domain name TLV SHOULD be present in an EAP-Initiate/ 
Re-auth-Start message. 
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In addition, channel binding information MAY be included; see 
Section 5.5 for discussion. See Figure 12 for parameter 
specification. 


5.3.1.1. Authenticator Operation 


In order to minimize ERP failure times, the authenticator SHOULD send 
the EAP-Initiate/Re-auth-Start message to indicate support for ERP to 
the peer and to initiate ERP if the peer has already performed full 
EAP authentication and has unexpired key material. The authenticator 
SHOULD include the Domain name TLV to allow the peer to learn it 
without requiring either lower-layer support or the ERP bootstrapping 
exchange. 


The authenticator MAY include channel binding information so that the 
server can verify whether the authenticator is claiming the same 
identity to both parties. 


The authenticator MAY retransmit the EAP-Initiate/Re-auth-Start 
message a few times for reliable transport. 


5.3.1.2. Peer Operation 


The peer SHOULD send the EAP-Initiate/Re-auth message in response to 
the EAP-Initiate/Re-auth-Start message from the authenticator. If 
the peer does not recognize the EAP-Initiate code value or if the 
peer has already sent the EAP-Initiate/Re-auth message to begin the 
ERP exchange, it MUST silently discard the EAP-Initiate/Re-auth-Start 
message. 


If the EAP-Initiate/Re-auth-Start message contains the domain name, 
and if the peer does not already have the domain information, the 
peer SHOULD use the domain name contained in the message to compute 
the DSRK and use the corresponding DS-rIK to send an EAP-Initiate/ 
Re-auth message to start an ERP exchange with the local ER server. 

If there is a local ER server between the peer and the home ER server 
and the peer has already initiated an ERP exchange with the local ER 
server, it SHOULD NOT start an ERP exchange with the home ER server. 


Cao, et al. Standards Track [Page 27] 


RFC 6696 


EAP Extensions for ERP 


5.3.2. EAP-Initiate/Re-auth Packet 


July 2012 


The EAP-Initiate/Re-auth packet contains the parameters shown in 


Figure 9. 


0 


1 2 


3 


012345678901234567890123456789021 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Code | Identifier | Length 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type |R|B|L| Reserved] SEQ 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| 1 or more TVs or TLVs Ñ 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Cryptosuite | Authentication Tag g 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Figure 9: EAP-Initiate/Re-auth Packet 
Type = 2 
Flags 
'R' —- The R flag is set to 0 and ignored upon reception. 
'B' — The B flag is used as the bootstrapping flag. If the 
flag is turned on, the message is a bootstrap message. 
'L’ - The L flag is used to request the key lifetimes from the 


server 


The remaining 5 bits are set to 0 on transmission and ignored 


on reception. 


SEO: An unsigned 16-bit sequence number is used for replay 
The SEQ field is initialized to 0 every time a new 
d. The field is encoded in network byte order. 


protection. 
rRK is derive 


TVs or TLVs: In 
and a value w 
number of oct 


keyName-NATI: 
The NAI is 


encoded in 
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the TV payloads, there is a l-octet type payload 
ith type-specific length. In the TLV payloads, 
there is a l-octet type payload and a l-octet length payload. 
The length field indicates the length of the value expressed in 


ets. 


This is carried in a TLV payload. 


Standards Track 


The Type is 1. 
variable in length, not exceeding 253 octets. 

The EMSKname is in the username part of the NAI and is 
hexadecimal values. The EMSKname is 64 bits in 
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length, and so the username portion takes up 16 octets. If 
the rIK is derived from the EMSK, the realm part of the NAI 
is the home domain name, and if the rIK is derived from a 
DSRK, the realm part of the NAI is the domain name used in 
the derivation of the DSRK. The NAI syntax is specified in 
Aboba, et al. [RFC4282]. Exactly one keyName-NAI attribute 
SHALL be present in an EAP-Initiate/Re-auth packet. 


In addition, channel binding information MAY be included; see 
Section 5.5 for discussion. See Figure 12 for parameter 
specification. 

Cryptosuite: This field indicates the integrity algorithm used 
for ERP. Key lengths and output lengths are either indicated 
or are obvious from the cryptosuite name. We specify some 
cryptosuites below: 

* 0 RESERVED 

* 1 HMAC-SHA256-64 
* 2 HMAC-SHA256-128 
* 3 HMAC-SHA256-256 


HMAC-SHA256-128 is mandatory to implement and SHOULD be enabled in 
the default configuration. 


Authentication Tag: This field contains the integrity checksum 
over the ERP packet, excluding the Authentication Tag field 
itself. The length of the field is indicated by the 
cryptosuite. 
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3. EAP-Finish/Re-auth Packet 


The EAP-Finish/Re-auth packet contains the parameters shown in 


F 


+— +—+—+—+ 


Cao, 


igure 10. 


0 


1 2 3 


01234567890123456789012345678090U1 


-+-+-+-+-+-+-+- 


Code 


Type 


+ 
a ON 
OS on 
-+-+-+-+-+-+-+-+- 


Cryptosuite | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Be 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Identifier | Length 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
B|L| Reserved | SEQ = 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
or more TVs or TLVs ~ 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Authentication Tag 


R 


+h+=+ 


Figure 10: EAP-Finish/Re-auth Packet 


The R flag is used as the Result flag. When set to 0, 
it indicates success, and when set to '1', it indicates 
a failure. 


The B flag is used as the bootstrapping flag. If the 
flag is turned on, the message is a bootstrap message. 


The L flag is used to indicate the presence of the rRK 
lifetime TLV. 


The remaining 5 bits are set to 0 on transmission and ignored 
on reception. 


SEO: An unsigned 16-bit sequence number is used for replay 
protection. The SEQ field is initialized to 0 every time a new 
rRK is derived. The field is encoded in network byte order. 
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TVs or TLVs: In the TV payloads, there is a l-octet type payload 
and a value with type-specific length. In the TLV payloads, 
there is a l-octet type payload and a l-octet length payload. 
The length field indicates the length of the value expressed in 
number of octets. 


keyName-NAI: This is carried in a TLV payload. The Type is 1. 
The NAI is variable in length, not exceeding 253 octets. 
EMSKname is in the username part of the NAI and is encoded 
in hexadecimal values. The EMSKname is 64 bits in length, 
and so the username portion takes up 16 octets. If the rIK 
is derived from the EMSK, the realm part of the NAI is the 
home domain name, and if the rIK is derived from a DSRK, the 
realm part of the NAI is the domain name used in the 
derivation of the DSRK. The NAI syntax is specified in 
[RFC4282]. Exactly one instance of the keyName-NAI 
attribute SHALL be present in an EAP-Finish/Re-auth message. 


rRK Lifetime: This is a TV payload. The Type is 2. The value 
field contains an unsigned 32-bit integer in network byte 


order representing the lifetime of the rRK in seconds. If 
the 'L” flag is set, the rRK Lifetime attribute SHOULD be 
present. 


rMSK Lifetime: This is a TV payload. The Type is 3. The 
value field contains an unsigned 32-bit integer in network 
byte order representing the lifetime of the rMSK in seconds. 
If the 'L” flag is set, the rMSK Lifetime attribute SHOULD 
be present. 


Domain name: This is a TLV payload. The Type is 4. The 
domain name is to be used as the realm in an NAI [RFC4282]. 
The Domain name attribute MUST be present in an EAP-Finish/ 
Re-auth message if the bootstrapping flag is set and if the 
local ER server sent a DSRK Request. 


List of cryptosuites: This is a TLV payload. The Type is 5. 
The value field contains a list of cryptosuites, each of 
size 1 octet. The cryptosuite values are as specified in 
Figure 9. The server SHOULD include this attribute if the 
cryptosuite used in the EAP-Initiate/Re-auth message was not 
acceptable and the message is being rejected. The server 
MAY include this attribute in other cases. The server MAY 
use this attribute to signal its cryptographic algorithm 
capabilities to the peer. 
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Authorization Indication: This is a TLV payload. The Type 
is 6. This attribute MAY be included in the EAP-Finish/ 
Re-auth message when a DSRK is delivered to a local ER 
server and if the home EAP server can verify the 
authorization of the local ER server to advertise the domain 
name included in the domain TLV in the same message. The 
value field in the TLV contains an authentication tag 
computed over the entire packet, starting from the first bit 
of the code field to the last bit of the Cryptosuite field, 
with the value field of the Authorization Indication TLV 
filled with all Os for the computation. The key used for 
the computation MUST be derived from the EMSK with key label 
"DSRK Delivery Authorized Key@ietf.org" and optional data 
containing an ASCII string representing the key management 
domain for which the DSRK is being derived. 


In addition, channel binding information MAY be included: see 
Section 5.5 for discussion. See Figure 12 for parameter 
specification. The server sends this information so that the 
peer can verify the information seen at the lower layer, if 
channel binding is to be supported. 


Cryptosuite: This field indicates the integrity algorithm and the 
PRF used for ERP. Key lengths and output lengths are either 
indicated or are obvious from the cryptosuite name. 


Authentication Tag: This field contains the integrity checksum 
over the ERP packet, excluding the Authentication Tag field 
itself. The length of the field is indicated by the 
cryptosuite. 


5.3.4. TV and TLV Attributes 


The TV attributes that may be present in the EAP-Initiate or 
EAP-Finish messages are of the following format: 


0 1 2 3 
QT ¿2 340561 7 80920: 1.2 3) Aso 6108 9: 0041.-.2: 38-405: 060 8:09000:.1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Type | Value 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 11: TV Attribute Format 
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The TLV attributes that may be present in the EAP-Initiate or 
EAP-Finish messages are of the following format: 


0 


1 2 3 


OL 2 34 D0" PB 95 OAs 293) Ae 6 8 OS O AA BAS 0 8, OO: LL 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Type 


| Length | Value 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 12: TLV Attribute Format 


The following Types are defined in this document: 


‘1’ — keyName-NAI: This is a TLV payload. 


‘2’ — rRK Lifetime: This is a TV payload. 


/3' — rMSK Lifetime: This is a TV payload. 


‘4’ — Domain name: This is a TLV payload. 


‘5’ — Cryptosuite list: This is a TLV payload. 


‘6’ — Authorization Indication: This is a TLV payload. 


The TLV type range of 128-191 is reserved to carry channel binding 
information in the EAP-Initiate/Re-auth and EAP-Finish/Re-auth 


messages. 


TLVs) : 


"1287 


LAO 


'130’ 


IZI 


KZI 


Below are the current assignments (all of them are 


Called-Station-Id [RFC2865] 
Calling-Station-Id [RFC2865] 
NAS-Identifier [RFC2865] 
NAS-IP-Address [RFC2865] 


NAS-IPv6-Address [RFC3162] 


The length field indicates the length of the value part of the 
attribute in octets. 


5.4. Replay Protection 


For replay protection, ERP uses sequence numbers. The sequence 
number is maintained on a per rIK basis and is initialized to zero in 
both directions. In the first EAP-Initiate/Re-auth message, the peer 
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uses a sequence number value of zero or higher. Note that when the 
sequence number wraps back to zero, the rIK MUST be changed by 
running a full EAP authentication. The server expects a sequence 
number of zero or higher. When the server receives an EAP-Initiate/ 
Re-auth message, it uses the same sequence number in the EAP-Finish/ 


Re-auth message. The server then sets the expected sequence number 
to the received sequence number plus 1. The server MUST accept 
sequence numbers greater than or equal to the expected sequence 
number. 


If the peer sends an EAP-Initiate/Re-auth message but does not 
receive a response, it retransmits the request (with no changes to 
the message itself) a preconfigured number of times before giving up. 
However, it is plausible that the server itself may have responded to 
the message and the response was lost in transit. Thus, the peer 
MUST increment the sequence number and use the new sequence number to 
send subsequent EAP re-authentication messages. The peer SHOULD 
increment the sequence number by 1; however, it may choose to 
increment by a larger number. If the sequence number wraps back to 
zero, the peer MUST run full EAP authentication. 


5.5. Channel Binding 


ERP provides a protected facility to carry channel binding (CB) 
information, according to the guidelines provided by Aboba, 

et al. (see Section 7.15 of [RFC3748]). The TLV type range of 
128-191 is reserved to carry CB information in the EAP-Initiate/ 
Re-auth and EAP-Finish/Re-auth messages. Called-Station-Id, 
Calling-Station-Id, NAS-Identifier, NAS-IP-Address, and 
NAS-IPv6-Address are some examples of channel binding information 
listed in RFC 3748, and they are assigned values 128-132. Additional 
values are managed by IANA, based on IETF Review (formerly called 
"IETF Consensus") [RFC5226]. 


The authenticator MAY provide CB information to the peer via the 
EAP-Initiate/Re-auth-Start message. The peer sends the information 
to the server in the EAP-Initiate/Re-auth message; the server 
verifies whether the authenticator identity available via AAA 
attributes is the same as the identity provided to the peer. 


If the peer does not include the CB information in the EAP-Initiate/ 
Re-auth message, and if the local ER server’s policy requires channel 
binding support, it SHALL send the CB attributes for the peer’s 
verification. The peer attempts to verify the CB information if the 
authenticator has sent the CB parameters, and it proceeds with the 
lower-layer security association establishment if the attributes 
match. Otherwise, the peer SHALL NOT proceed with the lower-layer 
security association establishment. 
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6. 


Lower-Layer Considerations 


The authenticator is responsible for retransmission of EAP-Initiate/ 
Re-auth-Start messages. The authenticator MAY retransmit the message 
a few times or until it receives an EAP-Initiate/Re-auth message from 
the peer. The authenticator might not know if the peer supports ERP; 
in those cases, the peer could be silently discarding the 
EAP-Initiate/Re-auth-Start packets. Thus, retransmission of these 
packets should be kept to a minimum. The exact number is up to each 
lower layer. 


The Identifier value in the EAP-Initiate/Re-auth packet is 
independent of the Identifier value in the EAP-Initiate/Re-auth-Start 
packet. 


The peer is responsible for retransmission of EAP-Initiate/Re-auth 
messages. 


Retransmitted packets MUST be sent with the same Identifier value in 
order to distinguish them from new packets. By default, where the 
EAP-Initiate message is sent over an unreliable lower layer, the 
retransmission timer SHOULD be dynamically estimated. A maximum of 
3-5 retransmissions is suggested [RFC3748]. Where the EAP-Initiate 
message is sent over a reliable lower layer, the retransmission timer 
SHOULD be set to an infinite value so that retransmissions do not 
occur at the EAP layer. Please refer to RFC 3748 for additional 
guidance on setting timers. 


The Identifier value in the EAP-Finish/Re-auth packet is the same as 
the Identifier value in the EAP-Initiate/Re-auth packet. 


If an authenticator receives a valid duplicate EAP-Initiate/Re-auth 
message for which it has already sent an EAP-Finish/Re-auth message, 
it MUST resend the EAP-Finish/Re-auth message without reprocessing 
the EAP-Initiate/Re-auth message. To facilitate this, the 
authenticator SHALL store a copy of the EAP-Finish/Re-auth message 
for a finite amount of time. The actual value of time is a local 
matter; this specification recommends a value of 100 milliseconds. 


The lower layer may provide facilities for exchanging information 
between the peer and the authenticator about support for ERP, for the 
authenticator to send the domain name information and channel binding 
information to the peer. 
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Note that to support ERP, lower-layer specifications may need to be 
revised. Specifically, RFC 5996 must be updated to include EAP code 
values higher than 4 in order to use ERP with Internet Key Exchange 
Protocol version 2 (IKEv2). IKEv2 may also be updated to support 
peer-initiated ERP for optimized operation. Other lower layers may 
need similar revisions. 


Our analysis indicates that some EAP implementations are not RFC 3748 
compliant in that instead of silently dropping EAP packets with code 
values higher than 4, they may consider it an error. To accommodate 
such non-compliant EAP implementations, additional guidance has been 
provided below. Furthermore, it may not be easy to upgrade all the 
peers in some cases. In such cases, authenticators may be configured 
to not send EAP-Initiate/Re-auth-Start messages; peers may learn 
whether an authenticator supports ERP via configuration or from 
advertisements at the lower layer. 


In order to accommodate implementations that are not compliant to 
RFC 3748, such lower layers SHOULD ensure that both parties support 
ERP; this is trivial, for instance, when using a lower layer that is 
known to always support ERP. For lower layers where ERP support is 
not guaranteed, ERP support may be indicated through signaling (e.g., 
piggybacked on a beacon) or through negotiation. Alternatively, 
clients may recognize environments where ERP is available based on 
preconfiguration. Other similar mechanisms may also be used. When 
ERP support cannot be verified, lower layers may mandate falling back 
to full EAP authentication to accommodate EAP implementations that 
are not compliant to RFC 3748. 


7. AAA Transport of ERP Messages 


AAA transport of ERP messages is specified by Hoeper, 
et al. [RFC5749] and Bournelle, et al. [DIAMETER-ERP]. 


8. Security Considerations 
This section provides an analysis of the protocol in accordance with 
the AAA key management guidelines described by Housley & Aboba 
[RFC4962]. 


Cryptographic algorithm independence 


ERP satisfies this requirement. The algorithm chosen by the 
peer for the MAC generation is indicated in the EAP-Initiate/ 
Re-auth message. If the chosen algorithm is unacceptable, the 


EAP server returns an EAP-Finish/Re-auth message indicating a 
failure. Algorithm agility for the KDF is specified in 
Salowey, et al. [RFC5295]. Only when the algorithms used are 
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deemed acceptable does the server proceed with the derivation 
of keys and verification of the proof of possession of relevant 
key material presented by the peer. A full-blown negotiation 
of algorithms cannot be provided in a single round-trip 
protocol. Hence, while the protocol provides algorithm 
agility, it does not provide true negotiation. 


Strong, fresh session keys 


ERP results in the derivation of strong, fresh keys that are 
unique for the given session. An rMSK is always derived on 
demand when the peer requires a key with a new authenticator. 
The derivation ensures that the compromise of one rMSK does not 
result in the compromise of another rMSK at any time. 


Limited key scope 


The scope of all the keys derived by ERP is well defined. The 
rRK and rIK are never shared with any entity and always remain 
on the peer and the server. The rMSK is provided only to the 
authenticator through which the peer performs the ERP exchange. 
No other authenticator is authorized to use that rMSK. 


Replay detection mechanism 


For replay protection of ERP messages, a sequence number 
associated with the rIK is used. The sequence number is 
maintained by the peer and the server and is initialized to 
zero when the rIK is generated. The peer increments the 
sequence number by one after it sends an ERP message. The 
server sets the expected sequence number to the received 
sequence number plus one after verifying the validity of the 
received message and responds to the message. 


Authenticating all parties 


ERP provides mutual authentication of the peer and the server. 
Both parties need to possess the key material that resulted 
from a previous EAP exchange in order to successfully derive 
the required keys. Also, both the EAP re-authentication 
Response and the EAP re-authentication Information messages are 
integrity protected so that the peer and the server can verify 
each other. When the ERP exchange is executed with a local ER 
server, the peer and the local server mutually authenticate 
each other via that exchange in the same manner. The peer and 
the authenticator authenticate each other in the secure 
association protocol executed by the lower layer, just as in 
the case of a regular EAP exchange. 
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Peer and authenticator authorization 


The peer and authenticator demonstrate possession of the same 
key material without disclosing it, as part of the lower-layer 
secure association protocol. Channel binding with ERP may be 
used to verify consistency of the identities exchanged, when 
the identities used in the lower layer differ from those 
exchanged within the AAA protocol. 


Key material confidentiality 


The peer and the server derive the keys independently using 
parameters known to each entity. The AAA server sends the DSRK 
of a domain to the corresponding local ER server via the AAA 
protocol. Likewise, the ER server sends the rMSK to the 
authenticator via the AAA protocol. 


Note that compromise of the DSRK results in compromise of all 
keys derived from it. Moreover, there is no forward secrecy 
within ERP. Thus, compromise of a DSRK retroactively 
compromises all ERP keys. 


It is RECOMMENDED that the AAA protocol be protected using 
IPsec or Transport Layer Security (TLS) so that the keys are 
protected in transit. Note, however, that keys may be exposed 
to AAA proxies along the way, and compromise of any of those 
proxies may result in compromise of keys being transported 
through them. 


The home EAP server MUST NOT hand out a given DSRK to a local 
domain server more than once, unless it can verify that the 
entity receiving the DSRK after the first time is the same 
entity that received the DSRK originally. If the home EAP 
server verifies authorization of a local domain server, it MAY 
hand out the DSRK to that domain more than once. In this case, 
the home EAP server includes the Authorization Indication TLV 
to assure the peer that DSRK delivery is secure. 


Confirming cryptosuite selection 


Cryptographic algorithms for integrity and key derivation in 
the context of ERP MAY be the same as that used by the EAP 
method. In that case, the EAP method is responsible for 
confirming the cryptosuite selection. Furthermore, the 
cryptosuite is included in the ERP exchange by the peer and 
confirmed by the server. The protocol allows the server to 
reject the cryptosuite selected by the peer and provide 
alternatives. When a suitable rIK is not available for the 
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peer, the alternatives may be sent in an unprotected fashion. 
The peer is allowed to retry the exchange using one of the 


allowed cryptosuites. However, in this case, any en route 
modifications to the list sent by the server will go 
undetected. If the server does have an rIK available for the 


peer, the list will be provided in a protected manner and this 
issue does not apply. 


Uniquely named keys 


All keys produced within the context of ERP can be referred to 
uniquely as specified in this document. Also, the key names do 
not reveal any part of the key material. 


Preventing the domino effect 


The compromise of one peer does not result in the compromise of 
key material held by any other peer in the system. Also, the 
rMSK is meant for a single authenticator and is not shared with 
any other authenticator. Hence, the compromise of one 
authenticator does not lead to the compromise of sessions or 
keys held by any other authenticator in the system, and ERP 
thereby allows prevention of the domino effect by appropriately 
defining key scope. 


However, if keys are transported using hop-by-hop protection, 
compromise of a proxy may result in compromise of key material, 
e.g., the DSRK being sent to a local ER server. 


Binding a key to its context 


All the keys derived for ERP are bound to the appropriate 


context using appropriate key labels. The lifetime of a child 
key is less than or equal to that of its parent key as 
specified in RFC 4962 [RFC4962]. The key usage, lifetime, and 


the parties that have access to the keys are specified. 
Confidentiality of identity 


Deployments where privacy is a concern may find that the use of 
the rIKname-NAI to route ERP messages serves their privacy 
requirements. Note that it is plausible to associate multiple 
runs of ERP messages, since the rIKname is not changed as part 
of ERP. There was no consensus for that requirement at the 
time of development of this specification. If the rIKname is 
not used and the Peer-ID is used instead, the ERP exchange will 
reveal the Peer-ID over the wire. 
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Authorization restriction 


All the derived keys are limited in lifetime by that of the 
parent key or by server policy. Any domain-specific keys are 
further restricted for use only in the domain for which the 
keys are derived. All the keys specified in this document are 
meant for use in ERP only. Other restrictions on the use of 
session keys may be imposed by the specific lower layer but are 
out of scope for this specification. 


Preventing a DoS attack 


A denial-of-service (DoS) attack on the peer may be possible 
when using the EAP-Initiate/Re-auth message. An attacker may 
send a bogus EAP-Initiate/Re-auth message, which may be carried 
by the authenticator in a AAA-Request to the server; in 
response, the server may send in a AAA reply an EAP-Finish/ 
Re-auth message indicating failure. Note that such attacks may 
be possible with the EAPoL-Start capability of IEEE 802.11 and 
other similar facilities in other link layers and where the 
peer can initiate EAP authentication. An attacker may use such 
messages to start an EAP method run, which fails and may result 
in the server sending a rejection message, thus resulting in 
the link-layer connections being terminated. 


To prevent such DoS attacks, an ERP failure should not result 
in deletion of any authorization state established by a full 
EAP exchange. Alternatively, the lower layers and AAA 
protocols may define mechanisms to allow two link-layer 
Security Associations (SAs) derived from different EAP key 
material for the same peer to exist so that smooth migration 
from the current link-layer SA to the new one is possible 
during rekey. These mechanisms prevent the link-layer 
connections from being terminated when a re-authentication 
procedure fails due to a bogus EAP-Initiate/Re-auth message. 


Key material transport 


When a DSRK is sent from the home EAP server to a local domain 
server or when an rMSK is sent from an ER server to an 
authenticator, in the absence of end-to-end security between 
the entity that is sending the key and the entity receiving the 
key, it is plausible for other entities to get access to keys 
being sent to an ER server in another domain. This mode of key 
transport is similar to that of MSK transport in the context of 
EAP authentication. We further observe that ERP is for access 
authentication and does not support end-to-end data security. 
In typical implementations, the traffic is in the clear beyond 
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the access control enforcement point (the authenticator or an 
entity delegated by the authenticator for access control 
enforcement). The model works as long as entities in the 
middle of the network do not use keys intended for other 
parties to steal service from an access network. If that is 
not achievable, key delivery must be protected in an end-to-end 
manner. 


IANA Considerations 


The previous version of this document -- [RFC5296] -- performed the 
following IANA [IANA] actions: 


Is 


It registered Packet Codes "Initiate" and "Finish" in the EAP 
Registry. Those codes are referred to as "EAP-Initiate" and 
"EAP-Finish" throughout this document. 


It created a Message Types table in the EAP Registry and 
registered several items in that table. Those items are referred 
to as "Re-auth-start" and "Re-auth" throughout this document. 


It created an EAP-Initiate and Finish Attributes table in the EAP 
registry and registered several items in that table. Those items 
are recorded in this document in Section 5.3.4. 


It created a Re-authentication Cryptosuites table in the EAP 
registry and registered several items in that table. Those items 
are recorded in this document at the end of Section 5.3.2. 


It registered two items in the USRK Key Labels registry: 


*  Re-auth usage label "EAP Re-authentication Root Key@ietf.org", 
recorded in this document in Section 4.1. 


* DSRK-authorized delivery key "DSRK Delivery Authorized 
Key@ietf.org", recorded in this document in the description of 
"Authorization Indication" in Section 5.3.3. 
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Appendix B. Sample ERP Exchange 


0. Authenticator --> Peer: 
EAP-Initiate/Re-auth-Start [Optional] 


1. Peer --> Authenticator: 
EAP-Initiate/Re-auth(SEQ, keyName-NAI, cryptosuite, 
Auth-tag*) 


la. Authenticator --> Re-auth-Server: 
AAA-Request 
{ 
Authenticator-Id, 
EAP-Initiate/Re-auth(SEQ, keyName-NAI, cryptosuite, 
Auth-tag*) 
) 


2. ER-Server --> Authenticator: 
AAA-Response 
{ 
rMSK, 
EAP-Finish/Re-auth (SEQ, keyName-NAI, cryptosuite, [CB-Info], 
Auth-tag*) 
) 


2b. Authenticator --> Peer: 
EAP-Finish/Re-auth(SEQ, keyName-NAI, cryptosuite, [CB-Info], 
Auth-tag*) 


* Auth-tag computation is over the entire EAP-Initiate/Finish 


message; the code values for Initiate and Finish are different, 
and thus reflection attacks are mitigated. 
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